Software products are generally shipped by software vendors as individual versions of their product, with each successive version being identified by a different version number (for example, version 1.0, version 1.1, version 2.0). In a complex software product, such as an enterprise system product, it is also common for a particular version of the product to be provided with cumulative sub versions or service packs (for example, a 2.0 version of the product may be updated to version 2.0.1, or version 2.0.SP1). In some instances a software “patch” can be provided to patch an existing version of the product (for example, the product may be updated or patched from a version 2.0 to a patched version 2.0). Patching may be used to introduce new components into the system, or to address a particular shortcoming, feature or flaw in an existing version of the product. Such additional components, service packs, and patches are often generated and provided after the product has shipped, in response to customer requests for modified features, or to fix software bugs that are only discerned after the product has been in use for some time.
In the field of enterprise software systems, such as application servers, most software companies ship their products on a platform paradigm, wherein the products are generally sold as a platform or suite of products. As such, updates to a portion of the platform or suite must be coordinated so that they do not conflict with other portions of the platform or suite. This can complicate the process of providing updates, and causes delays in providing those updates to the end customer.